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Abstract 

Software-defined networking (SDN) programs must simul¬ 
taneously describe static forwarding behavior and dynamic 
updates in response to events. Event-driven updates are crit¬ 
ical to get right, but difficult to implement correctly due to 
the high degree of concurrency in networks. Existing SDN 
platforms offer weak guarantees that can break application 
invariants, leading to problems such as dropped packets, 
degraded performance, security violations, etc. This paper 
introduces event-driven consistent updates that are guaran¬ 
teed to preserve well-defined behaviors when transitioning 
between configurations in response to events. We propose 
network event structures (NESs) to model constraints on 
updates, such as which events can be enabled simultane¬ 
ously and causal dependencies between events. We define 
an extension of the NetKAT language with mutable state, 
give semantics to stateful programs using NESs, and discuss 
provably-correct strategies for implementing NESs in SDNs. 
Einally, we evaluate our approach empirically, demonstrat¬ 
ing that it gives well-defined consistency guarantees while 
avoiding expensive synchronization and packet buffering. 

Categories and Subject Descriptors C.2.3 [Computer- 
communication Networks]: Network Operations—Network 
Management; D.3.2 [Programming Languages]: Language 
Classifications—Specialized application languages; D.3.4 
[Programming Languages]: Processors—Compilers 

Keywords network update, consistent update, event struc¬ 
ture, software-defined networking, SDN, NetKAT 

1. Introduction 

Software-defined networking (SDN) allows network behav¬ 
ior to be specified using logically-centralized programs that 


execute on general-purpose machines. These programs re¬ 
act to events such as topology changes, traffic statistics, 
receipt of packets, etc. by modifying sets of forwarding 
rules installed on switches. SDN programs can implement 
a wide range of advanced network functionality including 
fine-grained access control [ 8 ], network virtualization [ 22 ], 
traffic engineering [15, 16], and many others. 

Although the basic SDN model is simple, building so¬ 
phisticated applications is challenging in practice. Pro¬ 
grammers must keep track of numerous low-level details 
such as encoding configurations into prioritized forwarding 
rules, processing concurrent events, managing asynchronous 
events, dealing with unexpected failures, etc. To address 
these challenges, a number of domain-specific network pro¬ 
gramming languages have been proposed [2, 10, 19, 21, 29, 
31, 36, 37]. The details of these languages vary, but they all 
offer higher-level abstractions for specifying behavior (e.g., 
using mathematical functions, boolean predicates, relational 
operators, etc.), and rely on a compiler and run-time system 
to generate and manage the underlying network state. 

Unfortunately, the languages that have been proposed so 
far lack critical features that are needed to implement dy¬ 
namic, event-driven applications. Static languages such as 
NetKAT [2] offer rich constructs for describing network con¬ 
figurations, but lack features for responding to events and 
maintaining internal state. Instead, programmers must write 
a stateful program in a general-purpose language that gener¬ 
ates a stream of NetKAT programs. Dynamic languages such 
as ElowLog and Kinetic [21, 31] offer stateful programming 
models, but they do not specify how the network behaves 
while it is being reconfigured in response to state changes. 
Abstractions such as consistent updates provide strong guar¬ 
antees during periods of reconfiguration [26, 33], but cur¬ 
rent realizations are limited to properties involving a single 
packet (or set of related packets, such as a unidirectional 
flow). To implement correct dynamic SDN applications to¬ 
day, the most effective option is often to use low-level APIs, 
forgoing the benefits of higher-level languages entirely. 

Example: Stateful Firewall. To illustrate the challenges 
that arise when implementing dynamic applications, con¬ 
sider a topology where an internal host Hi is connected to 
switch si, an external host H 4 is connected to a switch 54 , 
and switches si and 54 are connected to each other (see Eig- 
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ure 1). Suppose we wish to implement a stateful firewall; at 
all times, host Hi is allowed to send packets to host H^, but 
H/i should only be allowed to send packets to iJi if pre¬ 
viously initiated a connection. Implementing even this sim¬ 
ple application turns out to be difficult, because it involves 
coordinating behavior across multiple devices and packets. 
The basic idea is that upon receiving a packet from Hi at 
S 4 , the program will need to issue a command to install a 
forwarding rule on 54 allowing traffic to flow from H/i back 
to Hi. There are two straightforward (but incorrect) imple¬ 
mentation strategies on current SDN controllers. 

1. The outgoing request from Hi is diverted to the con¬ 
troller, which sets up flow tables for the incoming path 
and also forwards the packet(s) to H^^. Reconfiguring 
flow tables takes time, so i? 4 ’s response will likely be 
processed by the default drop rule. Even worse, if the re¬ 
sponse is the SYN-ACK in a TCP handshake, normal re¬ 
transmission mechanisms will not help—the client will 
have to wait for a timeout and initiate another TCP con¬ 
nection. In practice, this greatly increases the latency of 
setting up a connection, and potentially wreaks havoc on 
application performance. 

2. The outgoing request is buffered at the controller, which 
sets up the flow tables for the incoming path but waits un¬ 
til the rules are installed before forwarding the packet(s). 
This avoids the problem in (1), but places extra load 
on the controller and also implements the firewall incor¬ 
rectly, since incoming traffic is allowed before the outgo¬ 
ing request is delivered. Leaving the network unprotected 
(even briefly) can be exploited by a malicious attacker. 

Thus, while it is tempting to think that reliability mecha¬ 
nisms built into protocols such as TCP already prevent (or at 
least reduce) these types of errors, this is not the case. While 
it is true that some applications can tolerate long latencies, 
dropped packets, and weak consistency, problems with up¬ 
dates do lead to serious problems in practice. As another 
example, consider an intrusion detection system that mon¬ 
itors suspicious traffic—inadvertently dropping or allowing 
even a few packets due to a reconfiguration would weaken 
the protection it provides. The root of these problems is that 
existing SDN frameworks do not provide strong guarantees 
during periods of transition between configurations in re¬ 
sponse to events. An eventual guarantee is not strong enough 
to implement the stateful firewall correctly, and even a con¬ 
sistent update [33] would not suffice, since consistent up¬ 
dates only dictate what must happen to individual packets. 


Existing Approaches. Experienced network operators may 
be able to use existing tools/methods to correctly implement 
event-driven configuration changes. However, as seen above, 
this requires thinking carefully about the potential interleav¬ 
ings of events and updates, delegating atomic operations to 
the controller (incurring a performance hit), etc. 

As mentioned, there are stateful programming systems 
that attempt to make this process easier for the programmer, 
but update strategies in these systems either offer no consis¬ 
tency guarantees during dynamic updates, rely on expensive 
processing via the controller, and/or require the programmer 
to craft an update protocol by hand. In this paper, we group 
these approaches together, using the term uncoordinated up¬ 
date to describe their lack of support for coordinating local 
updates in a way that ensures global consistency. 

Event-Driven Consistent Update. We propose a new se¬ 
mantic correctness condition with clear guarantees about up¬ 
dates triggered by events. This enables specification of how 
the network should behave during updates, and enables pre¬ 
cise formal reasoning about stateful network programs. 

An event-driven consistent update is denoted as a triple 
Ci Cf, where Ci and Cy are the initial and final con¬ 
figurations respectively, and e is an event. Intuitively, these 
configurations describe the forwarding behaviors of the net¬ 
work before/after the update, while the event describes a 
phenomenon, such as the receipt of a packet at a particular 
switch, that triggers the update itself. Semantically, an event- 
triggered consistent update ensures that for each packet: 

1 . the packet is forwarded consistently, i.e. it must be pro¬ 
cessed entirely by a single configuration Ci or Cf, and 

2 . the update does not happen too early, meaning that if 
every switch traversed by the packet has not heard about 
the event, then the packet must be processed by Ci, and 

3. the update does not happen too late, meaning that if every 
switch traversed by the packet has heard about the event, 
then the packet must be processed by C/. 

The first criterion requires that updates are consistent, which 
is analogous to a condition proposed previously by Reitblatt 
et al. [33]. However, a consistent update alone would not 
provide the necessary guarantees for the stateful firewall 
example, as it applies only to a single packet, and not to 
multiple packets in a bidirectional flow. The last two criteria 
relate the packet-processing behavior on each switch to the 
events it has “heard about.” Note that these criteria leave 
substantial flexibility for implementations: packets that do 
not satisfy the second or third condition can be processed by 
either the preceding or following configuration. It remains to 
define what it means for a switch s to have “heard about” an 
event e that occurred at switch t (assuming s ^ t). We use 
a causal model and say that s hears about e when a packet, 
which was processed by t after e occurred, is received at s. 
This can be formalized using a “happens-before” relation. 

Returning to the stateful firewall, it is not hard to see that 
the guarantees offered by event-driven consistent updates are 
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sufficient to ensure correctness of the overall application. 
Consider an update Ci Cf.lnCi,Hi can send packets 
to H4, but not vice-versa. In C/, additionally H4 can send 
packets to H4. The event e is the arrival at 54 of a packet 
from Hi to H4. Before e occurs, can H4 send a packet to 
Hi, as is possible in Cfl No, since none of the switches 
along the necessary path have heard about the event. Now, 
imagine that the event e occurs, and H4 wants to send a 
packet to Hi afterwards. Can 54 drop the new packet, as it 
would have done in the initial configuration Q? No, because 
the only switch the packet would traverse is S4, and S4 has 
heard about the event, meaning that the only possible correct 
implementation should process this new packet in Cf. 

Event-Driven Transition Systems. To specify event-driven 
network programs, we use labeled transition systems called 
event-driven transition systems (ETSs). In an ETS, each 
node is annotated with a network configuration and each 
edge is annotated with an event. Eor example, the stateful 
firewall application would be described as a two-state ETS, 
one state representing the initial configuration before Hi has 
sent a packet to H4, and another representing the configu¬ 
ration after this communication has occurred. There would 
be a transition between the states corresponding to receipt of 
a packet from Hi to H4 at 54. This model is similar to the 
finite state machines used in Kinetic [ 21 ] and EAST [ 30 ]. 
However, whereas Kinetic uses uncoordinated updates, we 
impose additional constraints on our ETSs which allow them 
to be implemented correctly with respect to our consistency 
property. Eor example, we extend event-triggered consistent 
updates to sequences, requiring each sequence of transitions 
in the ETS to satisfy the property. Eor simplicity, in this pa¬ 
per, we focus on finite state systems and events correspond¬ 
ing to packet delivery. However, these are not fundamental 
assumptions—our design extends naturally to other notions 
of events, as well as infinite-state systems. 

Network Event Structures. The key challenge in imple¬ 
menting event-driven network programs stems from the fact 
that at any time, the switches may have different views of 
the global set of events that have occurred. Hence, for a given 
ETS, several different updates may be enabled at a particular 
moment of time, and we need a way to resolve conflicts. We 
turn to the well-studied model of event structures [ 38 ], which 
allows us to constrain transitions in two ways: (1) causal de¬ 
pendency, which requires that an event ei happens before 
another event 62 may occur, and (2) compatibility, which 
forbids sets of events that are in some sense incompatible 
with each other from occurring in the same execution. We 
present an extension called network event structure (NES), 
and show how an ETS can be encoded as an NES. 

Locality. While event-driven consistent updates require 
immediate responses to local events (as in the firewall), they 
do not require immediate reactions to events “at a distance.” 
This is achieved by two aspects of our definitions. 


The first defining aspect of our locality requirements in¬ 
volves the happens-before (“heard-about”) relation in event- 
driven consistent update. Eor example, the receipt of a packet 
in New York can not immediately affect the behavior of 
switches in London. Intuitively, this makes sense: requiring 
“immediate” reaction to remote events would force synchro¬ 
nization between switches and buffering of packets, leading 
to unacceptable performance penalties. Event-driven consis¬ 
tent update only requires the switches in London to react 
after they have heard about the event in New York. 

The second defining aspect of our locality requirements 
involves the compatibility constraints in NESs. Suppose that 
New York sends packets to London and Paris, but the pro¬ 
gram requires transitioning to a different global state based 
on who received a packet first. Clearly, it would be impossi¬ 
ble to implement this behavior without significant coordina¬ 
tion. However, suppose New York and Philadelphia are send¬ 
ing packets to London, and the program requires transition¬ 
ing to a different global state based on whose packet was re¬ 
ceived first in London. This behavior is easily implementable 
since the choice is local to London. We use NESs to rule out 
non-local incompatible events—specifically, we require that 
incompatible events must occur at the same switch. 

Our approach gives consistency guarantees even when an 
event occurs at a switch different from the one that will be 
updated. The change will not happen “atomically” with the 
event that triggered it, but (a) every packet is processed by 
a single configuration, and (b) the configuration change oc¬ 
curs as dictated by event-driven consistent update (happens- 
before) requirements. We show that these requirements can 
be implemented with minimal performance penalty. 

Locality issues are an instance of the tension between 
consistency and availability in distributed systems, which 
motivates existing SDN languages to favor availability 
(avoiding expensive synchronization and packet buffering) 
over consistency (offering strong guarantees when state 
changes). We demonstrate that it is possible to provide the 
same level of availability as existing systems, while provid¬ 
ing a natural consistency condition that is powerful enough 
to build many applications. We also show that weakening 
the locality requirement forces us to weaken availability. 

Overall, we present a new abstraction based on (i) a no¬ 
tion of causal consistency requiring that events are propa¬ 
gated between nodes, (ii) per-packet consistency governing 
how packets are forwarded through the network, and (iii) lo¬ 
cality requirements. We believe this is a powerful combina¬ 
tion that is a natural fit for building many applications. 

Implementing Network Programs. NESs also provide a 
natural formalism for guiding an implementation technique 
for stateful programs. Intuitively, we need switches that can 
record the set of events that have been seen locally, make 
decisions based on those events, and transmit events to other 
switches. Eortunately, in the networking industry there is a 
trend toward more programmable data planes: mutable state 
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is already supported in most switch ASICs (e.g. MAC learn¬ 
ing tables) and is also being exposed to SDN programmers in 
next-generation platforms such as OpenState [5] and P4 [6]. 
Using these features, we can implement an NES as follows. 

1. Encode the sets of events contained in the NES as flat tags 
that can be carried by packets and tested on switches. 

2. Compile the configurations contained in the NES to a 
collection of forwarding tables. 

3. Add “guards” to each configuration’s forwarding rules to 
explicitly test for the tag enabling the configuration. 

4. Add rules to “stamp” incoming packets with tags corre¬ 
sponding to the current set of events. 

5. Add rules to “learn” which events have happened by 
reading tags on incoming packets and adding the tags in 
the local state to outgoing packets, as required to imple¬ 
ment the happens-before relation. 

In this paper, we prove that a system implemented in this 
way correctly implements an NES. 

Evaluation. To evaluate our design, we built a prototype 
of the system described in this paper.f We have used this to 
build a number of event-driven network applications: (a) a 
stateful firewall, which we have already described; (b) a 
learning switch that floods packets going to unknown hosts 
along a spanning tree, but uses point-to-point forwarding for 
packets going to known hosts; (c) an authentication system 
that initially blocks incoming traffic, but allows hosts to gain 
access to the internal network by sending packet probes to a 
predefined sequence of ports; (d) a bandwidth cap that dis¬ 
ables access to an external network after seeing a certain 
number of packets; and (e) an intrusion detection system that 
allows all traffic until seeing a sequence of internal hosts 
being contacted in a suspicious order. We have also built 
a synthetic application that forwards packets around a ring 
topology, to evaluate update scalability. We developed these 
applications in an extended version of NetKAT which we 
call Stateful NetKAT. Our experiments show that our imple¬ 
mentation technique provides competitive performance on 
several important metrics while ensuring important consis¬ 
tency properties. We draw several conclusions. (1) Event- 
driven consistent update allow programmers to easily write 
real-world network applications and get the correct behav¬ 
ior, whereas approaches relying only on uncoordinated con¬ 
sistency guarantees do not. (2) The performance overhead of 
maintaining state and manipulating tags (measured in band¬ 
width) is within 6% of an implementation that uses only un¬ 
coordinated update. (3) There is an optimization that exploits 
common structure in rules across states to reduce the num¬ 
ber of rules installed on switches. In our experiments, a basic 
heuristic version of this optimization resulted in a 32-37% 
reduction in the number of rules required on average. 

Summary. Our main contributions are as follows. 


t The PLDI 2016 Artifact Evaluation Committee (AEC) found that our 
prototype system “met or exceeded expectations.” 


• We propose a new semantic correctness condition for dy¬ 
namic network programs called event-driven consistent 
update that balances the need for immediate response 
with the need to avoid costly synchronization and buffer¬ 
ing of packets. Our consistency property generalizes the 
guarantees offered by consistent updates, and is as strong 
as possible without sacrificing availability. 

• We propose network event structures to capture causal 
dependencies and compatibility between events, and 
show how to implement these using SDN functionality. 

• We describe a compiler based on a stateful extension 
of NetKAT, and present optimizations that reduce the 
overhead of implementing such stateful programs. 

• We conduct experiments showing that our approach gives 
well-defined consistency guarantees, while avoiding ex¬ 
pensive synchronization and packet buffering. 

The rest of this paper is structured as follows: §2 formalizes 
event-driven consistent updates; §3 defines event transition 
systems, network event structures, and Stateful NetKAT; §4 
describes our implementation; and §5 presents experiments. 
We discuss related/future work in §6-7, and conclude in §8. 

2. Event-Driven Network Behavior 

This section presents our new consistency model for stateful 
network programs: event-driven consistent update. 

Preliminaries. A packet pkt is a record of fields {/i; / 2 ; 
■ ■ ■ ) fn}, where fields / represent properties such as source 
and destination address, protocol type, etc. The (numeric) 
values of fields are accessed via the notation pkt.f, and 
field updates are denoted pkt[f ^ n]. A switch sw is a 
node in the network with one or more ports pt. A host is 
a switch that can be a source or a sink of packets. A location 
I is a switch-port pair n:m. Locations may be connected by 
(unidirectional) physical links {Isrc, Idst) in the topology. 

Packet forwarding is dictated by a network configuration 
C. A located packet Ip = {pkt, sw, pt) is a tuple consisting 
of a packet and a location sw.pt. We model C as a rela¬ 
tion on located packets: if C{lp, Ip'), then the network maps 
Ip to Ip' , possibly changing its location and rewriting some 
of its fields. Since C is a relation, it allows multiple output 
packets to be generated from a single input. In a real net¬ 
work, the configuration only forwards packets between ports 
within each individual switch, but for convenience, we as¬ 
sume that our C also captures link behavior (forwarding be¬ 
tween switches), i.e. C{{pkt,ni,mi), {pkt,n2,m2)) holds 
for each link {ni:mi,n2.m2). We refer to a sequence of lo¬ 
cated packets that starts at a host and can be produced by C 
as a packet trace, using Traces {C) to denote the set of all 
such packet traces. We let C be the set of all configurations. 

Consider a tuple ntr = {Ip^lpi ■ ■ ■ ,T), where the first 
component is a sequence of located packets, and each t G T 
is an increasing sequence of indices corresponding to located 
packets in the sequence. We call such a tuple a network trace 
if and only if the following conditions hold: 
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1. for each Ipj, we have j G t for some t G T, and 

2. for each t = {koki • • •) G T, Ipf.^ is at a host, and 

3C G C such that C{lpj.., holds for all i, and 

3. if we consider the graph G with nodes {k : (3f G 

T : k G t)} and edges : (3t G T : t — 

knki ■ ■ ■ kiki+i •••)), then G is a family of trees rooted 
at K ^ {ko : (3t G T : t = ko ■ ■ ■)}. 

We will use ntr^k to denote the set {f G T ■. k G t}, and 
when f = (fcofci • • •) G T, we can use similar notation ntrlt 
to denote the packet trace Ipf.^ lpi._^ ■ ■ ■. Intuitively, we have 
defined a network trace to be an interleaving of these packet 
traces (the packet traces form the family of trees because, 
as previously mentioned, the configuration allows multiple 
output packets from a single input packet). Ultimately, we 
will introduce a consistency definition that dictates which 
interleavings of packet traces are correct. 

We now define how the network changes its configuration 
in response to events. An event e is a tuple {(p, sw,pt)eid, 
where eid is an (optional) event identifier and is a first- 
order formula over fields. Events model the arrival of a 
packet satisfying p (denoted pkt |= p) at location sw.pt. 
Note that we could have other types of events—anything that 
a switch can detect could be an event—^but for simplicity, we 
focus on packet events. We say that a located packet Ip = 
{pkt, sw', pt') matches an event e = {p,sw,pt) (denoted 
by Ip 1= e) if and only if sw = sw' A pt = pt' A pkt ^ p. 

Definition 1 (Happens-before relation -<ntr)- Given a net¬ 
work trace ntr = {Ip^lpi ■ ■ ■ , T), the happens-before rela¬ 
tion -<ntr is the least partial order on located packets that 

• respects the total order induced by ntr at switches, i.e., 
yi,j : Ipj^ A Ipj -4= J < j A /pj = {pkt, sw,pt) A Ipj = 
{pkt', sw,pt'), and 

• respects the total order induced by ntr for each packet, 
i.e., Vi, j ■. Ip ^ < Ip j ^ i < j A3t G T •. i G t A j G t. 

Event-Driven Consistent Update. In Section 1, we infor¬ 
mally defined an event-driven consistent update as a triple 
Ci Cf consisting of an initial configuration Ci, event e, 
and final configuration G/. Here, we formalize that defini¬ 
tion in a way that describes sequences of events and con¬ 
figurations (in the single-event case, this formal definition is 
equivalent to the informal one). We denote an event-driven 
consistent update as a pair {U,£), where U is a sequence 
Go ^ Gi ^ ^ G„+i, and {eo, • • • , e„} C f. 

Let ntr = {Ip^^lp^ ■ ■ ■ , T) be a network trace. Given an 
event-driven consistent update {U,£), we need the indices 
where the events from U first occurred. Specifically, we wish 
to find the sequence k^, - ■ ■ ,kn where Ipj does not match 
any e G £ for any j > kn, and the following properties hold 
for all 0 < i < n (assuming = —1 for convenience); 

• ki> ki-i, and 

• Ip^. matches e^, and for all j, if ki-i < j < ki then 
Ipj does not match (i.e., ki is the first occurrence of 
after the index fci_i), and 


HI 


H2 




H3 

<^>(s3 J<£ - >^s4J<^-> 

H4 


Figure 2: Example topology with four switches and hosts. 

• 3f G ntr\.ki such that t is in Traces {Ci) (intuitively, the 
event can be triggered only by a packet processed in 
the immediately preceding configuration). 

If such a sequence exists, it is unique, and we denote it by 
FO{ntr, U), shorthand for “first occurrences.” 

Definition 2 (Event-driven consistent update correctness). A 
network trace ntr = {Ip^lp^ ■ ■ ■ ,T) is correct with respect 
to an event-driven consistent update U = Cq Gi 
• • • —^ Cn+i, if FO{ntr, U) = k^, ■ ■ ■ ,kn exists, and for 
all 0 < i < n, the following holds for each packet trace 
ntr ft = Ip'qIp'i • • ■ where t G T: 

• ntrft is in Traces{C) for some C G {Gq, • • • , G„+i} 
(packet is processed entirely by one configuration), and 

• ifyj : Ip'j A IPki’ then ntrft is in Traces{C) for some 
C G {Go, ■ • • ,Ci\ (the packet is processed entirely in a 
preceding configuration), and 

• ifyj : Ipk- A Ip'j, then ntrl.t is in Traces{C) for some 
C G (Gj+i, • • • , G„+i} (the packet is processed entirely 
in a following configuration). 

To illustrate, consider Eigure 2. We describe an update 
Ci Cf. In the initial configuration Ci, the host Hi 
can send packets to H 2 , but not vice-versa. In the final 
configuration Cf, traffic from H 2 to Hi is allowed. Event 
e models the arrival to S 4 of a packet from Hi (imagine 
S 4 is part of a distributed firewall). Assume that e occurs, 
and immediately afterwards, H 2 wants to send a packet to 
Si. Can S 2 drop the packet (as it would do in configuration 
Ci)l Event-driven consistent updates allow this, as otherwise 
we would require S 2 to react immediately to the event at S 4 , 
which would be an example of action at a distance. Eormally, 
the occurrence of e is not in a happens-before relation with 
the arrival of the new packet to S 2 . On the other hand, if e.g. 
S 4 forwards some packets to si and S 2 before the new packet 
from H 2 arrives, si and S 2 would be required to change their 
configurations, and the packet would be allowed to reach Hi. 

Network Event Structures. As we have seen, event-driven 
consistent updates specify how the network should behave 
during a sequence of updates triggered by events, but addi¬ 
tionally, we want the ability to capture constraints between 
the events themselves. Eor example, we might wish to say 
that 62 can only happen after ei has occurred, or that 62 and 
63 cannot both occur in the same network trace. 

To model such constraints, we turn to the event struc¬ 
tures model introduced by Winskel [38]. Intuitively, an event 
structure endows a set of events £ with (a) a consistency 
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predicate {con) specifying which events are allowed to occur 
in the same sequence, and (b) an enabling relation (h) speci¬ 
fying a (partial) order in which events can occur. This is for¬ 
malized in the following definition (note that we use Qfin to 
mean “finite subset,” and Vfin{X) = {Y : Y 'P{X)}). 

Definition 3 (Event structure). An event structure is a tuple 
(£, con, h) where: 

• £ is a set of events, 

• con : {Vfin{£) —> Boolean) is a consistency predicate 
that satisfies con{X) A Y CX con{Y), 

• h : ( 7 ^(£) X £ —)■ Boolean) is an enabling relation that 
satisfies {X \- e) A X CY {Y h e). 

An event structure can be seen as defining a transition system 
whose states are subsets of £ that are consistent and reach¬ 
able via the enabling relation. We refer to such a subset an 
as an event-set (called “configuration” in [38]). 

Definition 4 (Event-set of an event structure). Given an 
event structure N = {£,con,\-), an event-set of N is any 
subset X C £ which is: (a) consistent: WY C^„ X, con(Y) 
holds, and (b) reachable via the enabling relation: for each 
e G X, there exists eo, ei, • • • , e„ G X where e„ = e and 
0 h {eo} and (eo, • • • , ei_i} h Cifor all 1 < i < n. 

We want to be able to specify which network configura¬ 
tion should be active at each event-set of the event structure. 
Thus, we need the following extension of event structures. 

Definition 5 (Network event structure (NES)). A network 
event structure is a tuple {£, con, h, g) where {£, con, h) is 
an event structure, and g : {'P{£) -A C) maps each event-set 
of the event structure to a network configuration. 

Correct Network Traces. We now define what it means for 
a network trace ntr to be correct with respect to an NES 
N = {£, con, \-,g). We begin by constructing a sequence S 
of events that is allowed by N. A sequence S' = epei • • • e„ 
is allowed by A^, if 0 h (eoj A con{{eo}), and VI < z < n : 
({eo, ei, • • • , ei_i} h A con{{eo, Ci, • • • , ej)). 

Intuitively, we say that ntr is correct if there is a sequence 
of events allowed by N which would cause ntr to satisfy the 
event-driven consistent update condition. 

Definition 6 (Correct network trace). Let S be the set of all 
sequences allowed by N. Formally, a network trace ntr = 
{IPqIPi ■ ■ ■ ,T) is correct with respect to N if 

• no Ipj matches any e G £, and for all packet traces ntr\.t 
where t G T,we have ntr It is in Traces {g (ill)), or 

• there exists some eoei ■ ■ ■ Cn G S such that ntr is correct 

with respect to event-driven consistent update (p( 0 ) 
v({eo}) gi{eo, ■■■ , e„}), S). 

Locality Restrictions for Incompatible Events. We now 
show how NESs can be used to impose reasonable local¬ 
ity restrictions. A set of events E is called inconsistent 
if and only if con{E) does not hold. We use the term 
minimally-inconsistent to describe inconsistent sets where 


all proper subsets are not inconsistent. An NES N is called 
locally-determined if and only if for each of its minimally- 
inconsistent sets E, all events in E happen at the same 
switch (i.e., BszyVci G E : Ci = {ipi, sw,ptf)). To illustrate 
the need for the locally-determined property, let us consider 
the following two programs. Pi and P 2 . 

• Program Pp. Recall that two events are inconsistent if ei¬ 
ther of them can happen, but both cannot happen in the 
same execution. Consider the topology shown in Eigure 2 
and suppose this program requires that iT2 and can 
both receive packets from Hi, but only the first one to 
receive a packet is allowed to respond. There will be two 
events Ci and 62 , with ci the arrival of a packet from Hi 
at S2, and 62 the arrival of a packet from Hi at S4. These 
events are always enabled, but the set {61,62} is not 
consistent, i.e. con({6i,62}) does not hold. This mod¬ 
els the fact that at most one of the events can take effect. 
These events happen at different switches—making sure 
that at most one of the events takes effect would neces¬ 
sitate information to be propagated instantaneously “at a 
distance.” In implementations, this would require using 
inefficient mechanisms (synchronization and/or packet 
buffering). Our locality restriction is a clean condition 
which ensures that the NES is efficiently implementable. 

• Program P 2 : Consider a different program where H 2 can 
send traffic to one of the two hosts Hi, H 3 that sends it a 
packet first. The two events (a packet from Hi arriving 
at S2, and a packet from H 3 arriving at S2) are still 
inconsistent, but inconsistency does not cause problems 
in this case, because both events happen at the same 
switch (the switch can determine which one was first). 

In contrast to our approach, an uncoordinated update ap¬ 
proach improperly handles locality issues, mainly because 
it does not guarantee when the configuration change occurs. 
Consider the program Pi again, and consider the (likely) 
scenario where events 61 and 62 happen nearly simultane¬ 
ously. In an uncoordinated approach, this could result in 
switch S 2 hearing about ei, 62 (in that order), and S 4 hear¬ 
ing about 62,61 (in that order), meaning the two switches 
would have conflicting ideas of which event was “first” (i.e. 
the switches would be in conflicting states, and this conflict 
cannot be resolved). In our implementation, we would re¬ 
quire 61 and 62 to occur at the same switch, guaranteeing 
that we never see such a conflicting mix of states. 

Strengthening Consistency. We now show that strength¬ 
ening the consistency conditions imposed by NESs would 
lead to lower availability, as it would lead to the need for ex¬ 
pensive synchronization, packet buffering, etc. Eirst, we will 
try to remove the locally-determined condition, and second, 
we will try to obtain a strengthened consistency condition. 
The proof of the following theorem is an adaptation of the 
proof of the CAP theorem [7], as presented in [13]. The idea 
is that in asynchronous network communication, a switch 
might need to wait arbitrarily long to hear about an event. 
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Lemma 1. In general, it is impossible to implement an NES 
that does not have the locally-determined condition while 
guaranteeing that switches process each packet within an a 
priori given time bound. 


(a) 






^ 2 ^ 

(b) 


ox: 




(c) 


Proof Sketch. Consider a simple NES, with event sets 0, 
{ei}, {62}, and where {ei} and {62} are both enabled from 
0. Assume that con({ei, 62}) does not hold, and that ei can 
happen at switch A and 62 can happen at switch B (i.e., the 
locally-determined condition does not hold). 

Because the communication is asynchronous, there is no 
a priori bound on how long the communication between 
switches can take. When a packet p that matches 62 arrives 
at the switch B, the switch must distinguish the following 
two cases: (#1) event ei has occurred at A (and thus p 
does not cause 62 ), or (# 2 ) event ei has not occurred at 
A (and thus p causes 62 ). No matter how long B waits, it 
cannot distinguish these two cases, and hence, when a packet 
that matches 62 arrives to B, the switch B cannot correctly 
decide whether to continue as if 62 has happened. It has 
the choice to either eventually decide (and risk the wrong 
decision), or to buffer the packet that matches 62 . □ 

We now ask whether we can strengthen the event-driven 
consistent update definition. We define strong update as an 
update Cl —C2 such that immediately after e occurred, the 
network processes all incoming packets in C 2 . We obtain the 
following lemma by the same reasoning as the previous one. 

Lemma 2. In general, it is impossible to implement strong 
updates and guarantee that switches process each packet 
within an a priori given time bound. 

Proof Sketch. Let A be the switch where e can happen, and 
let i? be a switch on which the configurations Ci, C 2 differ. 
For A and B, the same argument as in the previous lemma 
shows that B must either risk the wrong decision on whether 
to process packets using Ci or C 2 , or buffer packets. □ 

3. Programming with Events 

The correctness condition we described in the previous sec¬ 
tion offers useful application-level guarantees to network 
programmers. At a high level, the programmer is freed from 
thinking about interleavings of packets/events and responses 
to events (configuration updates). She can think in terms of 
our consistency model—each packet is processed in a single 
configuration, and packets entering “after” an event will be 
processed in the new configuration (similar to causal consis¬ 
tency). An important consequence is that the response to an 
event is immediate with respect to a given flow if the event 
is handled at that flow’s ingress switch. 

With this consistency model in mind, programmers can 
proceed by specifying the desired event-driven program be¬ 
havior using network event structures. This section intro¬ 
duces an intuitive method for building NESs using simple 
transition systems where nodes correspond to configurations 


Figure 3: Event-driven transition systems. 

and edges correspond to events. We also present a network 
programming language based on NetKAT that provides a 
compact notation for specifying both the transition system 
and the configurations at the nodes. 

3.1 Event-Driven Transition Systems 

Definition 7 (Event-driven Transition System). An event- 
driven transition system (ETS) is a graph {V,D,vo), in 
which V is a set of vertices, each labeled by a configuration; 
D C V X V is a set of edges, each labeled by an event e; 
and Vq is the initial vertex. 

Consider the ETSs shown in Figure 3 (a-b). In (a), the 
two events are intuitively compatible —they can happen in 
any order, so we obtain a correct execution if both happen 
in different parts of the network, and different switches can 
have a different view of the order in which they happened. 
In (b), the two events are intuitively incompatible —only one 
of them can happen in any particular execution. Therefore, 
even if they happen nearly simultaneously, only one of them 
should take an effect. To implement this, we require the lo¬ 
cality restriction—we need to check whether the two events 
happen at the same switch. We thus need to distinguish be¬ 
tween ETSs such as (a) and (b) in Figure 3, to determine 
where locality restrictions must be imposed in the conver¬ 
sion from an ETS to an NES. 

From ETSs to NESs. To convert an ETS to an NES, we 
first form the event sets (Definition 4) and then construct the 
enabling relation and consistency predicate. Given an ETS 
T, consider the set W (T) of sequences of events in T from 
the initial node to any vertex (including the empty sequence). 
For each sequence p G IV(T), let E{p) be the set of events 
collected along the sequence. The set F{T) = {Eijf) \ p e 
FE(T)} is our candidate collection of event sets. We now 
define conditions under which F{T) gives rise to an NES. 

1. We require that each set E in F{T) must correspond to 
exactly one network configuration. This holds if all paths 
in W (T) corresponding to E end at states labeled with 
the same configuration. 

2. We require that F{T) is finite-complete, i.e. for any sets 
El, E2, • • • , En where each Ei G F{T), if there is a set 
E' G F{T) which contains every Ei (an upper bound for 
the sets Ei), then the set Eiub = i->iEi (the least upper 
bound for the Efi must also be in F{T). For example, 
consider the ETS in Figure 3(c), which violates this con¬ 
dition since the event-sets Ei = {ei} and E 2 = { 63 } are 
both subsets of {ei, 64 , 63 }, but there is no event-set of 
the form EiU E 2 = {ci, 63 }. 
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In [38], such a collection F{T) is called family of config¬ 
urations. Our condition (2) is condition (i) in Theorem 1.1.9 
in [38] (conditions (ii)-(iii) are satisfied by construction). 

Given an ETS T, it is not difficult to confirm the above 
conditions statically. They can be checked using straight¬ 
forward graph algorithms, and any problematic vertices or 
edges in T can be indicated to the programmer. The develop¬ 
ment of efficient checking algorithms is left for future work. 

We build the con and h relations of an NES from the 
family F{T), using Theorem 1.1.12. of [38]. Specifically, 
predicate con can be defined by declaring all sets in F{T) as 
consistent, and for h, we take the smallest relation satisfying 
the constraints 0 h e {e} € F{T) and X' \- e 

{X' e con) A ((2f' U {e}) G F{T) V (3X C X' : X h e)). 

After obtaining an NES, deciding whether it satisfies 
the locality restriction is easy: we check whether the NES 
is locally determined (see Section 2), verifying for each 
minimally-inconsistent set that the locality restriction holds. 
Again, we leave the efficiency of this check for future work. 

Loops in ETSs. If there are loops in the ETS T, the pre¬ 
vious definition needs to be slightly modified, because we 
need to “rename” events encountered multiple times in the 
same execution. This gives rise to an NES where each event- 
set is finite, but the NES itself might be infinite (and thus 
can only be computed lazily). If we have the ability to store 
and communicate unbounded (but finite) event-sets in the 
network runtime, then no modifications are needed to han¬ 
dle infinite NESs in the implementation (which is described 
in Section 4). Otherwise, there are various correct overap¬ 
proximations we could use, such as computing the strongly- 
connected components (SCCs) of the ETS, enforcing the lo¬ 
cality restriction on events in each (non-singleton) SCC, and 
requiring the implementation to attach timestamps on occur¬ 
rences of events in those SCCs. Eor simplicity of the presen¬ 
tation, we will consider only loop-free ETSs in this paper. 

3.2 Stateful NetKAT 

NetKAT [2] is a domain-specific language for specifying 
network behavior. It has semantics based on Kleene Al¬ 
gebra with Tests (KAT), and a sound and complete equa- 
tional theory that enables formal reasoning about programs. 
Operationally, a NetKAT program behaves as a function 
which takes as input a single packet, and uses tests, field- 
assignments, sequencing, and union to produce a set of “his¬ 
tories” corresponding to the packet’s traces. 

Standard NetKAT does not support mutable state. Each 
packet is processed in isolation using the function described 
by the program. In other words, we can use a standard 
NetKAT program for specifying individual network config¬ 
urations, but not event-driven configuration changes. We de¬ 
scribe a stateful variant of NetKAT which allows us to com¬ 
pactly specify a collection of network configurations, as well 
as the event-driven relationships between them (i.e. an ETS). 
This variant preserves the existing equational theory of the 


/ G Field (packet fieldname) 

n G N (numeric value) 

X ::= f I pt (modifiablefield) 

a, b ::= true | false \ x = n \ sw=n | state(n) = n (test) 

I a V & I a A 6 I ~<a 

p, q ::= a\x-<^n\p-\-q\p;q\p* (command) 

I (n:n) — 1 > (n:n) | (n:n) —> (n:n) — » {state(n) t— n) 

Figure 4: Stateful NetKAT: syntax. 


[(a:b) 


[state(m)=n]g A 
(c:d) —0 (state(m) <— »r}]g = 


fltruejj if fc(m)=n 
1 [false] j; otherwise 
[(a:fe) ^ (c:(i)|g 


Figure 5: Stateful NetKAT: extracting NetKAT Program (state k). 


individual static configurations (though it is not a KAT it¬ 
self), but also allows packets to affect processing of future 
packets via assignments to (and tests of) a global state. The 
syntax of Stateful NetKAT is shown in Figure 4. A Stateful 
NetKAT program is a command, which can be: 

• a test, which is a formula over packet header fields (there 
are special fields sw and pt which test the switch- and 
port-location of the packet respectively), 

• a field assignment x^n, which modifies the (numeric) 
value stored in a packet’s field, 

• a union of commands p q, which unions together the 
packet-processing behavior of commands p and q, 

• a command sequence p ; q, which runs packet-processing 
program q on the result of p, 

• an iteration p*, which is equivalent to true +p -|- {p;p) + 

{p;p;p)-\ -, 

• or a link definition {ni:mi)—>{n2:m2), which forwards a 
packet from port mi at switch rii across a physical link 
to port m2 at switch n 2 . 

The functionality described above is also provided by stan¬ 
dard NetKAT [35]. The key distinguishing feature of our 
Stateful NetKAT is a special global vector-valued variable 
called state, which allows the programmer to represent a col¬ 
lection of NetKAT programs. The function shown in Figure 
5 gives the standard NetKAT program |p]j: corresponding 
to each value k of the state vector (for conciseness, we only 
show the non-trivial cases). We can use the NetKAT com¬ 
piler [35] to generate forwarding tables (i.e. configurations) 
corresponding to these, which we denote Gdpjj:). 

3.3 Converting Stateful NetKAT Programs to ETSs 

Now that we have the | • Jg function to extract the static con¬ 
figurations (NetKAT programs) corresponding to the ver¬ 
tices of an ETS, we define another function (| • \)^, which 
produces the event-edges (Figure 6). This collects (using pa¬ 
rameter ip) the conjunction of all tests seen up to a given 
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(l/©0feV5 = 

({},{‘FA/0n}) 


da A 6Dg f 

_A 

da ; 

dswSnDgv? - 

dtrueDj f 


da V 6Dg f 

A 

da-hfe^g f 

dportSnDgv? - 

dtrueDj f 


dtrueDg f 

A 


ds^a^e(m) © nDg - 

1 dtrue© f if k{m)^n 


dfalseDg f 

_A 

({},{}) 

1 dfalseDg f otherwise 


d^trueDg f 
d^falseDg f 

A 

_A 

dfalseDg f 
dtrueDg f 

= 

({},{(3/:p)A/=n}) 


d^(w 0 n)Dg f 

_A 

du 0 ^Dg f 

dp + aDfeV? = 

(Wfe v’) u (daDfc v>) 


d-i(aA6)Dg f 

_A 

daDfe ‘fi 

d-ia V ^6Dg f 

dp \q\)if = 

(Wfe ■ daDfc) v> 


_A 

dp*Dfc V = 

(Fk) 


d^(a V6)Dg f 

_A 

d-ia A ^6Dg f 

d(si:pi) 

d(si:pi) (S 2 :P 2 )D£ p 
(S 2 ;p 2 ) -> {state(m) t- n)Dg p 


i,P 2 ),k[m i-s- n])},{p}) 


Figure 6: Stateful NetKAT: extracting event-edges from state k. 


program location, and records a corresponding event-edge 
when a state assignment command is encountered. The func¬ 
tion returns a tuple {D, P), where D is a set of event-edges, 
and P is a set of updated conjunctions of tests. In the fig¬ 
ure, the U operator denotes pointwise union of tuples, i.e. 
(^ 1 , i?i, • • •) U {A2, B2, • • •) = {Ai U ^ 2 , Bi U B2, ■ ■ 
The ■ operator denotes (pointwise) Kleisli composition, i.e. 
(/ ■ ff) = U 2 / • 2 / ^ function F is as follows. 

The symbol variable 0 is either equality “=” or inequality 
‘0”, and @ is the opposite symbol with respect to 0. Given 
any conjunction ^p and a header field /, the formula (3/ : if) 
strips all predicates of the form (/ 0 n) from f. 

Using fst to denote obtaining the first element of a tuple, 
we can now produce the event-driven transition system for a 
Stateful NetKAT program p with the initial state ko: 

ETS{p)^ {V,D,vo) 
where V = Gdplg))} 

and P = /sf (UfcWfe true) 
and Vo = (fco, C'dpl^)) 

4. Implementing Event-Driven Programs 

Next, we show one method of implementing NESs in a real 
SDN, and we prove that this approach is correct—i.e., all 
traces followed by actual packets in the network are correct 
with respect to Definition 6 in Section 2. At a high level, the 
basic idea of our implementation strategy can be understood 
as follows. We assume that the switches in the network 
provide mutable state that can be read and written as packets 
are processed. Given an NES, we assign a tag to each event- 
set and compile to a collection of configurations whose rules 
are “guarded” by the appropriate tags. We then add logic 
that (i) updates the mutable state to record local events, (ii) 
stamps incoming packets with the tag for the current event- 


set upon ingress, and (iii) reads the tags carried by packets, 
and updates the event-set at subsequent switches. 

4.1 Implementation Building Blocks 

Static Configurations. The NES contains a set of network 
configurations that need to be installed as flow tables on 
switches. In addition, we must be able to transition to a new 
configuration in response to a local event. We do this proac¬ 
tively, installing all of the needed rules on switches in ad¬ 
vance, with each rule guarded by its configuration’s ID. This 
has a disadvantage of being less efficient in terms of rule- 
space usage, but an advantage of allowing quick configu¬ 
ration changes. In Section 5.3, we discuss an approach for 
addressing the space-usage issue by sharing rules between 
configurations. Our implementation strategy encodes each 
event-set in the NES as an integer, so a single unused packet 
header field (or single register on switches) can be used. This 
keeps the overhead low, even for very large programs. 

Stateful Switches. Emerging data-plane languages such as 
P4 [ 6 ] and OpenState [5] are beginning to feature advanced 
functionality such as customizable parsing, stateful memo¬ 
ries, etc. We assume that our switches support (1) modifying 
a local register (e.g. an integer on a switch) appropriately 
upon receipt of a packet, and ( 2 ) making packet forwarding 
decisions based on the value of a register. This allows each 
switch to maintain a local view of the global state. Specifi¬ 
cally, the register records the set of events the device knows 
have occurred. At any time, the device can receive a packet 
(from the controller or another device) informing it of new 
event occurrences, which are “unioned” into the local regis¬ 
ter (by performing a table lookup based on integer values). 
Currently, P4 data planes support this type of functionality. 

We also assume that the switch atomically processes each 
packet in the order in which it was received. Such “atomic” 
switch operations are proposed by the “Packet Transactions” 
P4 extension [34]. Because the P4 switch platform is attract¬ 
ing considerable attention (even spawning its own highly- 
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(Q, R, S) {Q, R, 5'^U{(n, gi, E, qm[m\-^pkts])}) 


Out 


E' = {e : {E U pkt.digest) h e A con{E U pkt.digest U {e}) A (pkt, n:m) \= e} 
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(ni:mi, n2'-m2) £ L S = S' U {{ni,qmi, Ei, qm2[mi ^ pktr.pkts]), (n2, qm^[m2 pkts'], E2, qm4)} 
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(Q, R, S) - 5 > (Q', R U {e}), S) (Q, R, S) - 5 > (Q, R, S' U {(n, qm, E U {e}, gma)}) 


Figure 7: Implemented program semantics. 


attended workshop), we feel that our assumptions are realis¬ 
tic for the current state-of-the-art in regards to switches. 

Packet Processing. Each packet entering the network is 
admitted from a host to a port on an edge switch. The 
configuration ID j corresponding to the device’s view of 
the global state is assigned to the packet’s version number 
field. The packet will processed only by j-guarded rules 
throughout its lifetime. Packets also carry a digest encoding 
the set of events the packet has heard about so far (i.e. 
the packet’s view of the global state). If the packet passes 
through a device which has heard about additional events, 
the packet’s digest is updated accordingly. Similarly, if the 
packet’s digest contains events not yet heard about by the 
device, the latter adds them to its view of the state. When a 
packet triggers an event, that event is immediately added to 
the packet’s digest, as well as to the state of the device where 
the event was detected. The controller is then notified about 
the event. Optionally (as an optimization), the controller 
can periodically broadcast its view of the global state to all 
switches, in order to speed up dissemination of the state. 

4.2 Operational Model 

We formalize the above via operational semantics for the 
global behavior of the network as it executes an NES. Each 
state in Eigure 7 has the form {Q, R, S), with a controller 
queue Q, a controller R, and set of switches S. Both the con¬ 
troller queue and controller are a set of events, and initially, 
R=Q=%. Each switch s € S' is a tuple (n, qmin, E, qmout), 
where n is the switch ID, qrriin, qmout are the input/out- 
put queue maps (mapping port IDs to packet queues). Map 
updates are denoted qm[m i—)■ pkts]. The event-set E rep¬ 
resents a switch’s view of what events have occurred. A 
packet’s digest is denoted pkt.digest, and the configuration 


corresponding to its version number is denoted pkt.C. The 
rules in Eigure 7 can be summarized as follows. 

• In/Out: move a packet between a host and edge port. 

• Switch; process a packet by first adding new events 
from the packet’s digest to the local state, then checking 
if the packet’s arrival matches an event e enabled by the 
NES and updating the state and packet digest if so, and 
finally updating the digest with other local events. 

• Link: move a packet across a physical link. 

• CtrlRecv: bring an event from the controller queue 
into the controller. 

• CtrlSend: update the local state of the switches. 

4.3 Correctness of the Implementation 

We now prove the correctness of our implementation. Eor- 
mally, we show that the operational semantics generates cor¬ 
rect traces, as defined in Section 2. 

Lemma 3 (Global Consistency). Given a locally-determined 
network event structure N, for an execution of the imple¬ 
mentation (Qi, Ri, Si){Q 2, R2, S2) ■ ■ ■ iQm,Rm,Sm), the 
event-set Qi U Ri is consistent for all 1 < i < m. 

Proof Sketch. We first show that if an inconsistent set Y 
where |F| > 1 satisfies the locality restriction (i.e. all of its 
events are handled at the same switch), then Y C RiU Qi is 
not possible for any i (the SWITCH rule ensures that multiple 
events from Y could not have been sent to the controller). 

We proceed by induction over to, the trace length, noting 
that the base case Qg U i?o = 0 is consistent. Assume that the 
implementation adds an e (via SWITCH) to some consistent 
event-set Qm U Rm, producing an inconsistent set. We look 
at the minimally-inconsistent set y C (QmUi?mU{e}), and 
notice that the locality restriction requires all events in Y to 
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be detected at the same switch, so by the previous paragraph, 
we must have |y | < 1. This generates a contradiction, since 
it would mean that either Y = {co} or F C U Rm, 
either of which would make Y consistent. □ 

Traces of the Implementation. Note that we can readily 
produce the network trace (Section 2) that corresponds to an 
implementation trace, since a single packet pkt is processed 
at each step of Figure 7. We now present the main result of 
this section—executions of the implementation correspond 
to correct network traces (Definition 6). 

Theorem 1 (Implementation Correctness). For an NFS N, 
and an execution Si){Q2t R2t S2) • • • {Qrm Rm, 

Sm) of the implementation, the corresponding network trace 
ntr is correct with respect to N. 

Proof Sketch. The proof is by induction over the length m 
of the execution. In the induction step, we show that (1) 
the Switch rule can only produce consistent event-sets 
(this follows directly from Lemma 3), and (2) when the In 
rule tags a packet pkt based on the local event-set E, that 
E consists of exactly the events that happened before pkt 
arrived (as ordered by the happens-before relation). □ 

5. Implementation and Evaluation 

We built a full-featured prototype implementation in OCaml. 

• We implemented the compiler described in Section 3. 
This tool accepts a Stateful NetKAT program, and pro¬ 
duces the corresponding NFS, with a standard NetKAT 
program representing the configuration at each node. We 
interface with Frenetic’s NetKAT compiler to produce 
flow-table rules for each of these NetKAT programs. 

• We modified the OpenFlow 1.0 reference implementation 
to support the custom switch/controller needed to realize 
the runtime described in Section 4. 

• We built tools to automatically generate custom Mininet 
scripts to bring up the programmer-specified network 
topology, using switches/controller running the compiled 
NFS. We can then realistically simulate the whole system 
using real network traffic. 

Research Questions. To evaluate our approach, we wanted 
to obtain answers to the following questions. 

1. How useful is our approach? Does it allow programmers 
to easily write real-world network programs, and get the 
behavior they want? 

2. What is the performance of our tools (compiler, etc.)? 

3. How much does our correctness guarantee help? For in¬ 
stance, how do the running network programs compare 
with uncoordinated event-driven strategies? 

4. How efficient are the implementations generated by our 
approach? For instance, what about message overhead? 
State-change convergence time? Number of rules used? 

We address #1-3 through case studies on real-world pro¬ 
gramming examples, and #4 through quantitative perfor¬ 


mance measurements on simple automatically-generated 
programs. For the experiments, we assume that the pro¬ 
grammer has first confirmed that the program satisfies the 
conditions allowing proper compilation to an NFS, and we 
assume that the FTS has no loops. Our tool could be modi¬ 
fied to perform these checks via basic algorithms operating 
on the FTS, but they have not yet been implemented in the 
current prototype (as mentioned in Section 3.1, developing 
efficient algorithms for these checks is left for future work). 
Our experimental platform was an Ubuntu machine with 
20GB RAM and a quad-core Intel i5-4570 CPU (3.2 GHz). 

To choose a representative set of realistic examples, we 
first studied the examples addressed in other recent state¬ 
ful network programming approaches, such as SNAP [3], 
FlowLog [31], Kinetic [21], NetFgg [39], and FAST [30], 
and categorized them into three main groups: 

• Protocols/Security: accessing streaming media across 
subnets, ARP proxy, firewall with authentication, FTP 
monitoring, MAC learning, stateful firewall, TCP re¬ 
assembly, Virtual Machine (VM) provisioning. 

• Measurement/Performance: heavy hitter detection, band¬ 
width cap management (uCap), connection affinity in 
load balancing, counting domains sharing the same IP 
address, counting IP addresses under the same domain, 
elephant flows detection, link failure recovery, load bal¬ 
ancing, network information base (NIB), QoS in multi- 
media streaming, rate limiting, sampling based on flow 
size. Snort flowbits, super spreader detection, tracking 
flow-size distributions. 

• Monitoring/Filtering: application detection, DNS ampli¬ 
fication mitigation, DNS TTL change tracking, DNS 
tunnel detection, intrusion detection system (IDS), 
optimistic ACK attack detection, phishing/spam detec¬ 
tion, selective packet dropping, sidejack attack detection, 
stolen laptop detection, SYN flood detection, UDP flood 
mitigation, walled garden. 

As we will see in the following section, our current prototype 
system is best suited for writing programs such as the ones in 
the Protocols/Security category, since some of the Measure¬ 
ment/Performance programs require timers and/or integer 
counters, and some of the Monitoring/Filtering programs re¬ 
quire complex pattern matching of (and table lookups based 
on) sequences of packets—functionality which we do not 
(yet) natively support. Thus, we have selected three exam¬ 
ples from the first category, and one from each of the latter 
two, corresponding to the boldface applications in the list. 
We believe that these applications are representative of the 
basic types of behaviors seen in the other listed applications. 

5.1 Case Studies 

In the first set of experiments, we compare correct behav¬ 
ior (produced by our implementation strategy) with that of 
an uncoordinated update strategy. We simulate an uncoordi¬ 
nated strategy in the following way: events are sent to the 
controller, which pushes updates to the switches (in an un- 
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Figure 8: Topologies: (a) Firewall, (b) Learning Switch, (c) Authentication, (d) Bandwidth Cap, (e) Intrusion Detection System. 


pt=2 A ip_dst=H4; pt-<— 1; (state=[0]; 

(1:1)—>(4:1)— i>(state-<—[ 1 ]) + state7^:[0]; 
(1:1)-|>(4:1)) ; pt^2 

(u) + pt=2 A ip_dst=Hl; states [1]; pt-^—l; 

(4:1)->(1:1); pt^2 


for each. We then plotted the total number of incorrectly- 
dropped packets with respect to delay. The results are shown 
in Figure 10. Note that even with a very small delay, the un¬ 
coordinated strategy still always drops at least one packet. 


pt=2 A ip_dst=Hl; (pt<-l; (4:l)-i.(l:l) + 

state^[0]; pt-<— 3; (4:3)—0(2:1)) ; pt-<—2 
(b) + pt=2 A ip_dst=H4; pt4— 1; (1:1)—o(4:l)—o( 

state-<—[ 1 ] ) ; pt-<— 2 
+ pt=2; pt<-l; (2:l)-i>(4:3); ptl-2 


state=[0] A pt=2 A ip_dst=Hl; pt-<— 1; 

(4:1)—>(1:1)— >(state-<— [ 1 ]); pt-^2 
+ state=[l] A pt=2 A ip_dst=H2; pt-<—3; 
(c) (4:3)—>(2:1)— >(state-<—[2 ]); pt-^2 

+ state=[2] A pt=2 A ip_dst=H3; pt-<—4; 
(4:4)->(3:l); pt-^-2 

+ pt-2; pt-i-1; ((1:1)->(4:1) + (2:l)->(4:3) + 
(3:l)-o(4:4)) ; pt<-2 


(d) 


pt=2 A ip_dst=H4; 

pt-^1; ( 

state= [0] ; (1:1)—>(4:1)— >(state-<— [1]) 

+ states [1]; (1:1)—>(4:1)— >(state-<— [2 ]) 
+ states [2]; (1:1)—>(4:1)— >(state-^ [3]) 


+ state=[10]; (1:1)—>(4:1)— >(state-<—[ 11 ]) 
+ state- [11]; (1:1)->(4:1) 

) ; pt-<— 2 

+ pt=2 A ip_dst=Hl; stated [11 ] ; pt-«-l; 

(4:1)->(1:1); pt-^-2 


pt=2 A ip_dst=Hl; pt-<— 1; (state=[0]; 

(4:1)—>(1:1)— >(state-^ [ 1 ]) + state^[0]; 

, (4:l)-o(l:l)); pt^2 

+ pt=2 A ip_dst=H2; pt4—3; (state=[l]; 

(4:3)—o(2:l)— o(state-<—[ 2 ]) + state^[l]; 
(4:3)-o(2:l)) ; ptl-2 

+ pt=2 A ip_dst=H3; pt4—4; stated [2]; 
(4:4)^(3:1); pt<-2 

+ pt=2; pt<-l; ((l:l)-i>(4:l) + (2:l)-i>(4:3) + 
(3:l)-o(4:4)) ; pt<-2 

Figure 9: Programs: (a) Firewall, (b) Learning Switch, (c) Authen¬ 
tication, (d) Bandwidth Cap, (e) Intrusion Detection System. 


predictable order) after a few-seconds time delay. We believe 
this delay is reasonable because heavily using the controller 
and frequently updating switches can lead to delays between 
operations of several seconds in practice (e.g. [17] reports up 
to 10s for a single switch update). 

To show that problems still arise for smaller delays, in the 
firewall experiment described next, we varied the time de¬ 
lay in the uncoordinated strategy between 0ms and 5000ms 
(in increments of 100ms), running the experiment 10 times 


Stateful Firewall. The example in Figures 8-9(a) is a sim¬ 
plified stateful firewall. It always allows “outgoing” traffic 
(from HI to H4), but only allows “incoming” traffic (from 
H4 to HI) after the outside network has been contacted, i.e. 
“outgoing” traffic has been forwarded to H4. 

Program p corresponds to configurations Cjo] = |p1[o] 
and Cfi] = |p][i]. In the former, only outgoing traffic is 
allowed, and in the latter, both outgoing and incoming are 
allowed. The ETS has the form {([0]) g4,4.i)^ ([I])}. 

The NFS has the form {Eo=% Ei={[dst=Hf 4:1)}}, 
where the g is given by g{Eo) = C[q], g{Ei) = C\i]. 

The Stateful Firewall example took 0.013s to compile, 
and produced a total of 18 flow-table rules. In Figure 11(a), 
we show that the running firewall has the expected behavior. 
We first try to ping HI from H4 (the “H4-Hl”/red points), 
which fails. Then we ping H4 from HI (the “Hl-H4”/orange 
points), which succeeds. Again we try H4-H1, and now this 
succeeds, since the event-triggered state change occurred. 

For the uncoordinated strategy. Figure 11(b) shows that 
some of the H1-H4 pings get dropped (i.e. HI does not hear 
back from H4), meaning the state change did not behave as 
if it was caused immediately upon arrival of a packet at S4. 

Learning Switch. The example in Figures 8-9(b) is a sim¬ 
ple learning switch. Traffic from H4 to HI is flooded (sent 
to both HI and H2), until H4 receives a packet from HI, at 



Figure 10: Stateful Firewall: impact of delay. 
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Figure 11: Stateful Firewall: (a) correct vs. (b) incorrect. 


which point it “learns” the address of HI, and future traffic 
from H4 to HI is sent only to HI. 

This program p corresponds to two configurations (^[o] = 
|p] [ 0 ] and (^[i] = |p] [ 1 ]. In the former, flooding occurs from 
H4, and in the latter, packets from H4 are forwarded directly 

to HI. The ETS has the form {([0]) ([!])}. 

The NES has the form {Ea=% Ei={{dst=H4., 4:1)}}, 

where the g is given by g{Eo) = Cfo], g{Ei) = Cfij. 

This only allows learning for a single host (HI), but we 
could easily add learning for H2 by using a different index 
in the vector-valued state held; we could replace state in 
Eigure 9(b) with state(O), and union the program (using the 
NetKAT “+” operator) with another instance of Eigure 9(b) 
which learns for H2 and uses state(l). 

The Learning Switch example took 0.015s to compile, 
and produced a total of 43 flow-table rules. We again com¬ 
pare the behavior of our correct implementation with that 
of an implementation which uses an uncoordinated update 
strategy. We first ping HI from H4. Expected behavior is 
shown in Figure 12(a), where the first packet is flooded to 
both HI and H2, but then H4 hears a reply from HI, causing 




(b) 


Figure 12: Learning Switch: (a) correct vs. (b) incorrect. 
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Figure 13: Authentication: (a) correct vs. (b) incorrect. 


the state change (i.e. learning Hi’s address), and all subse¬ 
quent packets are sent only to HI. In Figure 12(b), however, 
since the state change can be delayed, multiple packets are 
sent to H2, even after H4 has seen a reply from HI. 

Authentication. In this example, shown in Figures 8-9(c), 
the untrusted host H4 wishes to contact H3, but can only do 
so after contacting HI and then H2, in that order. 

This program p corresponds to three configurations: 
(7(0] = |p|[o] in which only H4-H1 traffic is enabled, 
^[1] = Ip1[i] in which only H4-H2 traffic is enabled, 
and C'[ 2 ] = |p|[ 2 ] which Anally allows H4 to communi¬ 
cate with H3. The ETS has the form {([0]) 

([!]) H 2 , 2 .i)^ ([2])}. The NES has the form {i?o=0 —>■ 

Ei={{dst=Hl, 1:1)} -)■ E 2 ={idst=Hl, l:l), {dst=H2, 
2:1)}}, where the g function is given by g{E[j) = C'[o], 
g{Ei) = C[i], g{E 2 ) = Cp]. 

The Authentication example took 0.017s to compile, and 
produced a total of 72 flow-table rules. In Figure 13(a) we 
demonstrate the correct behavior of the program, by first 
trying (and failing) to ping H3 and H2 from H4, then suc¬ 
cessfully pinging HI, again failing to ping H3 (and HI), and 
Anally succeeding in pinging H3. The incorrect (uncoordi¬ 
nated) implementation in Figure 13(b) allows an incorrect 
behavior where we can successfully ping HI and then H2, 
but then fail to ping H3 (at least temporarily). 

Bandwidth Cap. The Figure 8-9(d) example is a simplified 
bandwidth cap implementation. It allows “outgoing” traffic 
(H1-H4), but only until the limit of n packets has been 
reached, at which point the service provider replies with a 
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Figure 14: Bandwidth Cap: (a) correct vs. (b) incorrect. 


notification message, and disallows the “incoming” path. In 
this experiment, we use a bandwidth cap of n = 10 packets. 

Program p corresponds to configurations (^[o] = |p] [o], 
■ ■ ■ I C'fn] = IpI [n] ^ which all allow incoming/outgoing traffic, 
and a configuration C'[„_|_i] = |p][„_|_i] which disallows the 

incoming traffic. The ETS has the form {([0]) 

([!]) ^4 ^ — 4 {[n + 1 ])}. The NES 

has the form {Eq=% —>• Ei={{dst=HA:, 4 : 1 )} — i • • • —i 
En+i={{dst=HA, 4 :l)o, • • • , {dst=E[4:, 4 : 1 )„}}, where 
the g is given by g{Eo) = Cjoj, • • • ,fl(E^ri+i) = C[„+i]. 
Note that the subscripts on events in the NES event-sets 
(e.g. the ones in En+i) indicate “renamed” copies of the 
same event (as described in Section 3.1). 

The Bandwidth Cap example took 0.023s to compile, and 
produced a total of 158 flow-table rules. In Eigure 14(a), we 
show that the running example has the expected behavior. 
We send pings from HI to H4, of which exactly 10 succeed, 
meaning we have reached the bandwidth cap. Using the 
uncoordinated update strategy in Eigure 14(b), we again 
send pings from HI to H4, but in this case, 15 are successful, 
exceeding the bandwidth cap. 

Intrusion Detection System. In this example, shown in 
Eigures 8-9(e), the external host H4 is initially free to com¬ 
municate with the internal hosts HI, H2, and H3. However, 
if H4 begins engaging in some type of suspicious activity (in 
this case, beginning to scan through the hosts, e.g. contact¬ 
ing HI and then H2, in that order), the activity is thwarted 
(in this case, by cutting off access to H3). 

This program p corresponds to three configurations: 
C[o] = [p1[o] C[i\ = |p][i], in which all traffic is 
enabled, and Cp] = |p1 [2] in which H4-H3 communica¬ 
tion is disabled. The ETS has the form {([0]) 

([1]) g 2 , 2 .ij^ ([2])}. The NES has the form {Eq=% 

Ei={{dst=Hl, 1:1)1 ^ E 2 ={{dst=Hl, 1:1), (dsf=i/2, 
2:1)}}, where the g function is given by p(i?o) = (^[o], 
9{Ei) = C[i], g{E2) = C[2]. 
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Figure 15: Intrusion Detection System: (a) correct vs. (b) incorrect. 


This IDS example took 0.021s to compile and produced 
152 flow-table rules. In Figure 15(a), we demonstrate the 
correct behavior of the program, by first successfully ping¬ 
ing H3, H2, HI, H3, H2, HI (in that order) from H4. This 
results in a situation where we have contacted HI and then 
H2, causing the third attempt to contact H3 to be blocked 
(H4-H3 pings dropped). The incorrect (uncoordinated) im¬ 
plementation in Figure 15(b) allows a faulty behavior where 
we can successfully ping HI and then H2 (in that order), but 
subsequent H4-H3 traffic is still enabled temporarily. 

5.2 Quantitative Results 

In this experiment, we automatically generated some event- 
driven programs which specify that two hosts HI and H2 are 
connected to opposite sides of a ring of switches. Initially, 
traffic is forwarded clockwise, but when a specific switch 
detects a (packet) event, the configuration changes to for¬ 
ward counterclockwise. We increased the “diameter” of the 
ring (distance from HI to H2) up to 8 , as shown in Figure 
16, and performed the following two experiments. 

1. We used iperf to measure H1-H2 TCP/UDP band¬ 
width, and compared the performance of our running 
event-driven program, versus that of the initial (static) 
configuration of the program running on un-modified 
OpenFlow 1.0 reference switches/controller. Figure 16(a) 
shows that our performance (solid line) is very close to 
the performance of a system which does not do packet 
tagging, event detection, etc. (dashed line)—we see 
around 6 % performance degradation on average (note 
that the solid and dashed lines almost coincide). 
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Figure 16: Circular Example: (a) bandwidth (solid line is ours, 
dotted line is reference implementation) and (b) convergence. 



Figure 17: Heuristic: reducing the number of rules. 


2. We measured maximum and average time needed for a 
switch to learn about the event. The “Max.” and “Avg.” 
bars in Figure 16(b) are these numbers when the con¬ 
troller does not assist in disseminating events (i.e. only 
the packet digest is used), and the other columns are the 
maximum and average when the controller does so. 

5.3 Optimizations 

When a conhguration change occurs, the old and new conhg- 
urations are often similar, differing only in a subset of flow- 
table rules. Tables are commonly stored in TCAM memory 
on switches, which is limited/costly, so it is undesirable to 
store duplicate rules. As mentioned in Section 4.1, each of 
our rules is guarded by its configuration’s numeric ID. If the 
same rule occurs in several configurations having IDs with 
the same (binary) high-order bits, intuitively we can reduce 
space usage by keeping a single copy of the rule, and guard¬ 
ing it with a configuration ID having the shared high-order 
bits, and wildcarded low-order bits. For example, if rule r is 
used in two different configurations having IDs 2 (binary 10) 
and 3 (binary 11), we can wildcard the lowest bit (1*), and 
keep a single rule (l*)r having this wildcarded guard, in- 


0* , {ri} 1* , {r2} 

00,' 'Ol, 10,' 'll, 

{ri,r-2}{ri,r3}{r2,r3}{ri,r2} 

(a) 


0*,{ri,r2} l*,{r3} 

00,' 'Ol, 10,' 'll, 

{ri,r2}{ri,r2}{ri,r3}{r2,r-3} 

(b) 


Figure 18: Heuristic: two different tries for the same configurations. 


stead of two copies of r, with the “10” and “11” guards. Ide¬ 
ally, we would like to (re)assign numeric IDs to the configu¬ 
rations, such that maximal sharing of this form is achieved. 

We formalize the problem as follows. Assume there is a 
set of all possible rules TZ. A configuration C is a subset 
of these rules C C TZ. Assume there are k bits in a con¬ 
figuration ID. Without loss of generality we assume there 
are exactly 2^ configurations (if there are fewer, we can add 
dummy configurations, each containing all rules in TZ). For 
a given set of configurations, we construct a trie having all 
of the configurations at the leaves. This trie is a complete 
binary tree in which every node is marked with (1) a wild¬ 
carded mask that represents the configuration IDs of its chil¬ 
dren, and (2) the intersection of the rule-sets of its children. 

Consider configurations Cq = {ri,r 2 }, Ci = {ri,r3}, 
C 2 = C'a = { 1 ^ 1 ,^ 2 }- Figure 18 shows two differ¬ 

ent assignments of configurations to the leaves of tries. The 
number of rules for trie (a) is 6: (0*)ri , (00)r2 , (01)r3 , 
(l*)r2, {10)r3, (ll)ri. The number of rules for trie (b) is 5: 
(0*)ri , (0*)r2 , (l*)r3 , (lO)ri, (ll)r2. Intuitively, this is 
because the trie (b) has larger sets in the interior. Our poly¬ 
nomial heuristic follows that basic intuition: it constructs the 
trie from the leaves up, at each level pairing nodes in a way 
that maximizes the sum of the cardinalities of their sets. This 
does not always produce the global maximum rule sharing, 
but we find that it produces good results in practice. 

As indicated by the Figure 17 result (64 randomly- 
generate configurations w/ 20 rules), on average, rule sav¬ 
ings was about 32% of the original number of rules. We 
also ran this on the previously-discussed Firewall, Learning 
Switch, Authentication, Bandwidth Cap, and IDS examples, 
and got rule reductions of 18 —)■ 16, 43 —>■ 27, 72 —)■ 46, 
158 —>■ 101, and 152 —>■ 133 respectively. 

6. Related Work 

Network Updates, Verification, and Synthesis. We already 
briefly mentioned an early approach known as consistent 
updates [33]. This work was followed by update techniques 
that respect other correctness properties [25] [17] [40] [26]. 
These approaches for expressing and verifying correctness 
of network updates work in terms of individual packets. 

In event-driven network programs, it is necessary to 
check properties which describe interactions between multi¬ 
ple packets. There are several works which seek to perform 
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network updates in the context of multi-packet properties 
[12] [23]. There are also proposals for synthesizing SDN 
controller programs from multi-packet examples [39] and 
from first-order specifications [32]. Lopes et al. presented 
techniques for verifying reachability in stateful network pro¬ 
grams [24], using a variant of Catalog. This is a complimen¬ 
tary approach which could be used as a basis for verifying 
reachability properties of our stateful programs. 

Network Programming Languages. Network programs 
can often be constructed using high-level languages. The 
Frenetic project [10] [27] [11] allows higher-level specifica¬ 
tion of network policies. Other related projects like Merlin 
[36] and NetKAT [35] [4] provide high-level languages/tools 
to compile such programs to network configurations. Works 
such as Maple [37] and FlowLog [31] seek to address the 
dynamic aspect of network programming. 

None of these systems and languages provide both (1) 
event-based constructs, and (2) strong semantic guarantees 
about consistency during updates, while our framework en¬ 
ables both. Concurrently with this paper, an approach called 
SNAP [3] was developed, which enables event-driven pro¬ 
gramming, and allows the programmer to ensure consistency 
via an atomic language construct. Their approach offers a 
more expressive language than our Stateful NetKAT, but 
in our approach, we enable correct-by-construction event- 
based behavior and provide a dynamic correctness property, 
showing (formally) that is strong enough for easy reasoning, 
yet flexible enough to enable efficient implementations. We 
also prove the correctness of our implementation technique. 

Routing. The consistency/availability trade-off is of inter¬ 
est in routing outside the SDN context as well. In [18], a 
solution called consensus routing is presented, based on a 
notion of causality between triggers (related to our events). 
However, the solution is different in many aspects, e.g. it al¬ 
lows a transient phase without safety guarantees. 

High-Level Network Functionality. Some recent work 
has proposed building powerful high-level features into the 
network itself, such as fabrics [9], intents [1], and other vir¬ 
tualization functionality [22]. Pyretic [28] and projects built 
on top of it such as PyResonance [20], SDX [14], and Ki¬ 
netic [21] provide high-level operations on which network 
programs can be built. These projects do not guarantee con¬ 
sistency during updates, and thus could be profitably com¬ 
bined with an approach such as ours. 

7. Discussion and Future Work 

Generality of Our Approach. The event-driven SDN up¬ 
date problem considered in this paper is an instance of a 
more general distributed-systems programming problem, 
namely how to write correct and efficient programs for dis¬ 
tributed systems. We provide a PL approach (consistency 
property, programming language, and compiler/runtime) 
which ensures that the programmer need not reason about 


interleavings of events and updates for each application, and 
we show that our consistency model and implementation 
technique work well in the context of SDN programs, but 
we do not believe they are limited to that specific arena. Our 
approach could also possibly be extended to other distributed 
systems in which availability is prioritized, and consistency 
can be relaxed in a well-defined way, as in our event-driven 
consistent updates. Example domains include wireless sen¬ 
sor networks or other message-passing systems where the 
nodes have basic stateful functionality. 

Future Work. There are several directions for future work 
which could address limitations of our current system. 

1. We assume that the set of (potential) hosts is known in ad¬ 
vance, and use this information to generate correspond¬ 
ing flow tables for each switch. This may not be the right 
choice in settings where hosts join/leave. Our approach 
could be extended to represent hosts symbolically. 

2. We currently store all configurations on the switches, so 
that they are immediately available during updates. Our 
optimizations allow this to be done in a space-efficient 
way, but there may be situations when it would be better 
for the controller to reactively push new configurations to 
switches. This is an interesting problem due to interleav¬ 
ings of events and controller commands. 

3. It would be interesting to consider formal reasoning and 
automated verification for Stateful NetKAT. 

4. We provide a solution to the problem of performing mul¬ 
tiple updates, and the dynamic implementations we pro¬ 
duce are meant to “run” in the network indefinitely. How¬ 
ever, there may be ways to update the running dynamic 
program itself in some consistent way. 

8. Conclusion 

This paper presents a full framework for correct event-driven 
programming. Our approach provides a way of rigorously 
defining correct event-driven behavior without the need for 
specifying logical formulas. We detail a programming lan¬ 
guage and compiler which allow the user to write high-level 
network programs and produce correct and efficient SDN 
implementations, and we demonstrate the benefits of our ap¬ 
proach using real-world examples. This paper considers the 
challenging problem of distributing an event-based stateful 
network program, and solves it in a principled way. 
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